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ASSIMILATING  CASE  TOOLS  IN  ORGANIZATIONS: 
An  Empirical  Study  of  the  Process  and  Context  of  CASE  Tools 


ABSTRACT 

This  paper  describes  a  study  into  how  CASE  [Computer  Aided  Software  Engineering]  tools  are 
deployed  by  information  systems  units  within  organizations.  The  study  explored  the  process  by 
which  CASE  tools  are  assimilated  by  organizations,  and  how  this  process  is  influenced  by  various 
organizational  and  technological  factors.  Case  studies  of  eleven  companies  who  have  adopted  a 
single  CASE  tool  were  conducted,  and  the  findings  from  this  investigation  were  analyzed  in  terms 
of  the  conceptual  frameworks  of  innovation  research.  The  data  reveal  that  nominal  amounts  of  time 
and  effort  are  spent  on  evaluating  the  CASE  tools  prior  to  their  adoption,  and  that  as  a  result, 
organizational  consequences  of  these  tools  are  poorly  apprehended.  Further,  a  number  of  key 
factors  facilitating  and  inhibiting  the  process  of  CASE  tools  assimilation  were  identified.  The 
implications  of  these  findings  for  research  and  practice  are  discussed,  and  specific 
recommendations  for  managing  the  implementation  of  CASE  tools  are  provided 


1.  INTRODUCTION 

The  aim  of  the  study  reported  in  this  paper  was  to  systematically  examine  the  deployment  of  CASE 
(Computer  Aided  Software  Engineering)  tools  in  Information  Systems  (IS)  divisions  of 
organizations.  While  much  has  been  written  about  CASE  tools,  there  appears  to  be  little  empirical 
evidence  to  support  the  extravagant  claims  being  made  for  these  systems  development  aids.  The 
few  studies  that  have  been  undertaken  of  the  use  of  CASE  tools  in  organizations  have  typically 
focused  on  the  features  of  the  CASE  tools,  or  on  the  performance  outcomes  accruing  from  their 
utilization.  While  these  are  interesting  issues,  we  need  to  remember  that  tools  are  not  used  in  a 
vacuum,  but  rather  in  a  social  context.  And  the  interaction  of  a  technology  with  its  organizational 
context  plays  a  significant  role  in  shaping  outcomes.  Hence  we  propose  that  questions  about  the 
use  of  CASE  tools  need  to  take  account  of  organizational  dimensions,  for  example,  how  are  CASE 
tools  being  implemented  and  used  in  organizations?  what  changes  are  being  occasioned  by  this 
new  technology?  and  how  should  IS  organizations  accommodate  to  and  manage  these  changes? 

The  purpose  of  our  study  was  to  increase  understanding  of  the  process  by  which  organizations 
implement  and  assimilate  CASE  tools.  We  examined  the  CASE  tools  implementation  processes  of 
a  number  of  different  organizations,  and  on  the  basis  of  the  field  data  we  (i)  identified  the  sequence 
of  stages  by  which  CASE  tools  are  implemented  and  assimilated  into  organizations,  (ii)  articulated 
the  factors  that  facilitate  and  inhibit  this  implementation  and  assimilation  process,  and  (iii)  gained 
some  insight  into  the  organizational  consequences  of  CASE  tools'  deployment.  This  paper 
describes  the  study,  and  the  implications  for  research  and  practice  that  stem  from  it. 

This  paper  is  organized  as  follows.  Section  2  provides  the  groundwork  for  the  study  by  discussing 
CASE  tools  and  the  prior  research  that  has  been  undertaken  on  them.  Section  3  explains  the 
research  activities  we  pursued  to  investigate  the  process  of  CASE  tools  implementation  in  eleven 
organizations.  Section  4  describes  the  data  analysis  and  results,  and  section  5  provides  some 
implications  and  recommendations.  The  article  is  concluded  in  section  6  with  suggestions  for 
future  research. 

2.  SETTING  THE  SCENE 
2.1  CASE  Tools 

CASE  tools  mean  many  things  to  many  people.  There  is  no  well-accepted  definition,  but  most 
commentators  agree  that  they  encompass  all  or  some  subset  of  the  following  features:  for  the  front- 
end  conceptual  stages  of  systems  development,  such  as  analysis  assistance,  data  modeling  tools, 
data  dictionaries,  text  and  diagram  editors  (known  colloquially  as  upper  CASE);  and  for  the  back- 
end  implementation  stages  of  systems  development,  such  as  screen/report  design  aids,  code 
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generators,  testing  and  debugging  tools  (known  colloquially  as  lower  CASE)  [Henderson  & 
Cooprider  1988;  Rochester  1989].  Some  CASE  tools  are  bundled  together  (with  or  without 
explicit  integration)  and  sold  as  CASE  packages  or  toolsets.  There  is  currendy  a  wide  range  of 
CASE  tool  products  being  offered  in  the  market  (over  100  products  have  been  estimated  from  as 
many  vendors),  varying  from  stand-alone  first-generation  tools  (e.g.,  code  generators,  or 
diagramming  aids)  to  integrated,  second-generation  toolsets  (e.g.,  tool  environments  with 
centralized  data  dictionaries). 

2.2  Prior  Research 

Little  research  has  been  conducted  into  the  use  of  CASE  tools  in  organizations,  and  none  into  the 
process  of  deploying  and  assimilating  the  tools.  Most  of  the  general  literature  involves  a  discussion 
of  the  potential  of  CASE  tools  to  eliminate  software  backlogs  and  augment  the  quality  of  systems 
and  the  productivity  of  systems  developers  [Case  1985;  Freedman  1986;  Russell  1989;  Stamps 
1987].  While  some  of  these  benefits  may  be  realizable,  most  of  the  discussions  do  not  provide 
detailed  analyses  of  any  actual  CASE  technology  implementations.  The  mechanisms  through 
which  CASE  tools  are  to  be  successfully  deployed  so  as  to  accomplish  the  promised  benefits  are 
not  identified.  There  is  little  empirical  data  on  the  various  organizational  and  systems  development 
changes  that  result  from  using  automated  means  to  develop  information  systems.  The  few  available 
discussions  of  this  topic  raise  more  questions  than  they  answer  [Loh  &  Nelson  1989;  Rochester 
1989].  The  paucity  of  research  on  these  issues  means  that  little  is  understood  about  what  are  the 
options,  what  are  the  problems,  and  what  are  the  implications,  of  deploying  CASE  tools.  In  the 
next  section  we  describe  a  study  that  provides  some  insight  and  suggests  a  series  of 
recommendations  for  practitioners  using,  or  contemplating  investment  in,  CASE  tools. 

3.  RESEARCH  STUDY 

Given  the  tremendous  diversity  in  capabilities,  size,  scope,  price,  functionality,  computer 
requirements  and  education  demands  of  CASE  tool  products,  a  comparison  across  different  tools 
seems  futile.  A  standard  survey  across  tools  would  embody  too  much  variation,  noise,  and 
confounding  effects  to  provide  useful  knowledge  about  CASE  tools  in  general.  Hence  we  decided 
to  restrict  our  attention  to  a  single  CASE  toolset  product,  and  to  perform  a  series  of  comparative 
case  studies  that  would  examine  how  different  organizations  implemented  and  assimilated  the  same 
CASE  tool.  To  maximize  exposure  to  different  facets  of  CASE  tools,  we  chose  to  focus  on  one  of 
the  more  advanced  products,  a  second-generation  toolset  that  is  integrated  across  multiple  stages  of 


the  systems  development  life-cycle:  Information  Engineering  Workbench  (IEW).  The  EEW  toolset 
is  produced  by  KnowledgeWare  Inc.,  and  was  first  developed  in  1984.1 

3.1  Background  on  the  IEW  toolset 

The  Information  Engineering  Workbench  has  two  primary  organizing  principles:  (i)  that  all  the 
tools  (whether  for  planning,  analysis,  design,  or  programming)  are  linked  to  a  central 
"encyclopedia"  (storing  data  descriptions);  and  (ii)  that  the  tools  are  based  on  the  concepts  and 
precepts  of  a  systems  development  methodology,  Information  Engineering  (IE)  which  was 
developed  by  Martin  and  his  colleagues  [Martin  &  Finkelstein  1982].  The  premise  of  this 
methodology  is  that  information  systems  should  revolve  around  the  design  of  an  organization's 
data,  hence  it  has  been  termed  a  "data  oriented"  methodology  as  distinct  from  more  traditional 
systems  development  methodologies  that  are  "process  oriented."  The  IEW  set  of  tools  attempts  to 
provide  automated  support  for  all  aspects  of  the  systems  life  cycle,  from  strategic  planning  down 
to  code  generation  and  maintenance  [Desmond  1988].  The  platforms  on  which  EEW  can  operate 
include  microcomputer  as  well  as  mainframe  computers.  KnowledgeWare  has  sold  over  8000 
units  of  the  EEW  product  worldwide  [Desmond  1988],  and  currently  has  16%  of  the  installed 
CASE  tools  base,  second  behind  Excelerator  with  29%  market  share  [Gane  1988]. 

3.2  Sample 

We  obtained  a  list  of  EEW  customers  from  KnowledgeWare  who  met  the  following  criteria: 
substantial  financial  investment  in  EEW,  medium  to  large  sized  company,  a  diversity  of  industries, 
two  to  three  years  experience  with  EEW,  and  extensive  use  of  the  toolset  across  the  system  life 
cycle.  All  eleven  of  the  companies  we  contacted  agreed  to  participate.  The  distribution  of 
companies  by  industry,  size,  and  extent  of  use  with  EEW  are  indicated  in  Tables  1  through  4. 
Semi-structured  interviews  were  conducted  with  IS  directors  or  senior  IS  managers  designated  as 
responsible  for  EEW.  Subsequent  to  these  initial  interviews,  a  second  round  of  data  collection  was 
conducted  during  which  we  circulated  transcripts  of  interviews  to  participants  and  requested  their 
comments  and  clarification.  During  this  second  round  the  participants  gave  us  feedback  on  their 
prior  respondents  and  updated  us  on  other  issues  that  they  thought  relevant.  We  further 
interviewed  a  number  of  key  users  from  the  participating  companies  in  order  to  obtain  an 
alternative  perspective  on  the  implementation  of  CASE  tools  in  the  companies. 


1  While  currently  having  the  second  largest  share  of  the  CASE  tools  market  [Gane  1988],  the  future  viability  of 
EEW  seems  certain  given  the  recenUy  announced  marketing  partnership  between  KnowledgeWare  and  IBM,  the 
purchase  by  IBM  of  a  minority  equity  interest  in  KnowledgeWare,  and  the  intention  of  KnowledgeWare  to 
interface  with  IBM's  new  CASE  tool  offering  (a  Repository  product). 


Table  1:  Distribution  of  Companies  by  Industry 


INDUSTRY  TYPE 

NUMBER 

Aerospace 

1 

Financial  Services 

3 

Manufacturing 

3 

Telecommunications 

1 

Transportation 

2 

Utilities 

1 

Total 

11 

Table  2:  Distribution  of  Companies  by  Size 


SIZE   (Revenues) 

NUMBER 

Under  $100  million 

1 

$100 -$499  million 

1 

$500  -  999  million 

0 

$1- $10  billion 

5 

Over  $10  billion 

4 

Total 

11 

Table  3:  Length  of  time  IEW  used  by  Organizations 


MONTHS 

NUMBER 

0-  12 

0 

12-24 

6 

24-36 

4 

>36 

1 

Total 

11 

Table  4:  Number  of  Production  Systems  Developed  using  IEW 


SYSTEMS 

DEVELOPED 

NUMBER 

0 

2 

1 

2 

2 

3 

3-4 

1 

5-6 

2 

>6 

1 

Total 

11 

Average 

#  of 

Systems 

3.9 

3.3  Research  Questions 

No  existing  model  or  hypotheses  of  CASE  tools  assimilation  and  use  are  available,  so  our  study  is 
an  exploratory  one.  We  wanted  to  probe  a  series  of  topics  and  issues  regarding  the  implementation 
of  CASE  tools  with  the  participants.  These  topics  and  issues  reflect  prior  research  into  CASE  tools 
specifically,  and  the  literature  on  systems  development  and  implementation  more  generally.  Our 
research  interests  guided  our  discussion  of  topics  with  participants,  ensuring  our  attention  to  issues 
of  implementation,  consequences  and  the  factors  that  seemed  to  promote  or  constrain  the 
successful  deployment  of  CASE  tools.  The  interviews  thus  addressed  the  following  broad  areas: 
implementation  process,  organizational  changes  (including  structural,  performance,  and 
personnel),  and  technical  issues.  While  an  agenda  informed  our  interviews,  the  data  collection 
process  was  sufficiently  open-ended  to  allow  for  the  discussion  of  other  topics  and  issues.  Given 
the  exploratory  nature  of  our  study,  we  emphasize  that  the  results  obtained  and  discussed  below 
are  impressionistic,  and  are  to  be  understood  as  suggestive  rather  than  as  rigorous  or  definitive. 
Follow-up  research  to  refine  the  ideas  presented  here  is  clearly  needed  in  the  future. 

4.  DATA   ANALYSIS 

4.1  Stage  I:  Searching  for  Patterns 

We  initially  examined  the  data  on  content  alone,  to  identify  general  themes  that  seemed  related  to 
the  implementation  process,  and  factors  that  facilitated  or  constrained  this  process.  Having 
articulated  some  themes  across  the  companies,  we  attempted  to  make  some  sense  of  the  patterns  of 
data  that  had  emerged.  In  this  analysis  and  interpretation  process  we  found  the  conceptual 
apparatus  of  innovation  research  to  be  particularly  useful.  Adopting  Rogers'  [1983:22]  notion  of 
"innovativeness"  we  found  that  the  companies  we  had  investigated  could  be  differentiated  by  the 
extent  to  which  they  had  adopted  and  diffused  the  CASE  tools  within  their  units  or  organizations. 
While  the  innovation  framework  was  useful,  simply  ranking  companies  on  their  "degree  of 
innovativeness"  was  not  particularly  informative.  We  also  had  to  be  careful  which  studies  of 
organizational  innovativeness  we  relied  on,  as  many  have  been  criticized  for  oversimplifying  the 
process  of  diffusion  of  innovations  within  organizations,  and  for  inappropriately  transferring 
models  and  methods  of  innovativeness  from  the  individual  to  the  organizational  level  [Rogers 
1983:355). 

Given  our  primary  interest  in  the  process  of  CASE  tools  implementation,  we  found  those 
innovation  studies  that  focused  on  the  process  of  innovation  to  be  most  valuable,  as  these  were 
most  compatible  with  our  focus  on  how  different  organizations  implement  the  same  CASE  toolset. 
We  were  interested  in  the  process  an  organization  engages  in  when  assimilating  a  new  innovation. 


and  on  the  attributes  of  organizations  and  innovations  that  influence  this  assimilation.  We  were  less 
concerned  with  identifying  variables  that  discriminate  between  more  and  less  innovative 
organizations.  Thus  we  adopted  a  process,  as  opposed  to  a  variance  orientation.  We  examined  a 
number  of  innovation  process  frameworks  [Ginzberg  1979;  Kolb  &  Frohman  1970;  Lucas  1981; 
Meyer  &  Goes  1988;  Rogers  1983;  Rousseau  1989;  Schein  1969],  all  of  which  appear  to  extend 
and  elaborate  Simon's  [1960]  three  stage  model  of  the  decision-making  process  (intelligence  - 
design  -  choice)  to  the  level  of  organizational  innovation.  The  frameworks  differ  primarily  in  how 
specifically  they  detail  the  innovation  process,  whether  they  deal  with  innovation  in  general  or  with 
technological  innovation  in  particular,  and  whether  they  focus  only  on  rational  human  action  or 
allow  for  non-rational  (political  and  symbolic)  action.  The  framework  that  seemed  to  best  fit  our 
data  and  predilections  about  organizational  processes  was  Meyer  &  Goes'  [1988]  framework, 
which  is  highly  articulated,  deals  exclusively  with  technological  innovation,  and  recognizes  not 
only  economic  and  strategic  aspects  of  innovation,  but  also  social,  cultural  and  political  aspects. 

Meyer  &  Goes  [1988]  framework  of  the  process  of  innovation  assimilation  is  based  on  that 
articulated  by  Rogers  [1983:361-366],  but  goes  beyond  it  by  focusing  not  only  on  the  innovation 
process,  but  also  on  the  factors  that  influence  assimilation.  The  underlying  premise  of  Meyer  & 
Goes'  framework  is  that  innovations  in  general  are  seen  to  trigger  a  predictable  sequence  of 
cognitive,  social,  and  organizational  events.  The  framework  is  depicted  in  Table  5.  It  should  be 
noted  that  the  stages  are  presented  as  ideal  types,  hence  the  sequence  and  outcomes  of  innovation 
adoption  and  assimilation  can  and  typically  do  depart  from  this  representation.  The  framework, 
however,  does  provide  a  useful  structure  within  which  to  begin  to  interpret  empirical  data. 

Meyer  &  Goes  [1988:901]  elaborate  their  general  model  of  technological  innovation,  suggesting 
that  three  types  of  factors  influence  the  process  of  innovation  assimilation  in  organizations,  and 
that  these  factors  operate  within  the  framework  of  the  stages  articulated  in  Table  5.  The  three  factor 
types  are:  (i)  attributes  of  innovations,  which  include  how  risky  the  technology  is,  or  what  level  of 
skill  and  training  is  needed  to  use  the  technology;  (ii)  attributes  of  organizational  contexts,  which 
include  the  size  of  the  organization,  the  complexity  of  the  product/service  delivered,  and 
characteristics  of  employees;  and  (iii)  attributes  arising  from  the  interaction  of  innovations  and 
organizational  contexts,  which  include  the  compatibility  of  the  technology  with  the  characteristics 
of  the  employees,  and  the  extent  of  managerial  support  for  the  technological  innovation. 


Table  5:  General  Stages  in  the  Assimilation  of  Technological  Innovations 

[from  Meyer  &  Goes  1988:  903] 


KNOWLEDGE-AWARENESS  STAGE 

1 .  Apprehension:  Individuals  learn  of  an  innovation's  existence. 

2  .  Consideration:  Individuals  consider  the  innovation's  suitability. 

3  .  Discussion:  Individuals  engage  in  conversations  concerning  adoption. 

EVALUATION-CHOICE  STAGE 

4  .  Acquisition  Proposal:  Adoption  of  technology  is  proposed  formally. 

5  .  Rational  Evaluation:  The  proposed  investment  is  evaluated  according  to 

functional  and  financial  criteria. 

6.  Political-Strategic  Evaluation:  The  proposed  investment  is  evaluated 
according  to  political  and  strategic  criteria. 

ADOPTION-IMPLEMENTATION  STAGE 

7  .  Trial:  The  technology  is  acquired  but  remains  under  trial  evaluation. 

8 .  Acceptance:  The  technology  becomes  well  accepted  and  frequently  used. 

9 .  Expansion:  The  technology  is  expanded,  upgraded,  or  replaced  with  a 
second-generation  model. 


4.2  Stage  II:  Searching  for  Meaning 

Using  the  framework  of  Meyer  &  Goes  [1988],  we  returned  to  the  data,  and  analyzed  and 
categorized  the  interview  transcripts  searching  specifically  for  the  following  references: 
stage  in  the  assimilation  process  followed; 

-  factor  influencing  innovation  assimilation,  namely,  attribute  of  the  CASE  toolset, 
attribute  of  the  organizational  context,  and  attribute  of  the  interaction  between  the 
CASE  toolset  and  the  organization. 

All  of  the  companies  we  studied,  by  virtue  of  having  acquired  CASE  tools  while  the  majority  of 
U.S.  firms  have  not  yet  done  so,2  could  be  seen  to  be  innovative.  Where  they  differed,  however, 
was  in  their  assimilation  processes.  We  thus  distinguished  the  companies  on  their  degree  of 
assimilation  which  we  took  to  be  the  extent  of  CASE  tools  penetration  in  their  systems 
development  operations.  As  a  gauge  of  this  we  examined  the  number  of  production  systems  that 
had  ber n  completed  with  the  IEW  toolset  over  the  past  two  or  three  years.  Of  the  eleven  companies 
we  studied,  three  clearly  stood  out  in  their  implementation  of  CASE  tools,  having  five  or  more 
production  systems  completed  with  the  IEW  toolset.  Adapting  Rogers'  [1983:248-251]  innovation 
adopter  categories  to  the  case  of  innovation  assimilation,  we  will  call  them  early  assimilators,  as 
they  are  eager  to  implement  the  CASE  tools  and  reap  their  benefits,  without  taking  unnecessary 
risks.  Of  the  remaining  eight  companies,  six  fall  into  the  deliberators  group,  as  they  are  slower  and 
more  cautious  in  their  assimilation  of  CASE  tools,  only  having  completed  a  few  production 
systems  (one  to  four)  with  a  few  others  in  progress.  The  final  two  companies  are  part  of  the  late 
assimilators  group,3  having  completed  no  production  systems  with  IEW  yet,  and  being  skeptical 
and  more  reluctant  to  assimilate  CASE  tools  into  their  operations.  In  the  following  sections  we 
examine  the  patterns  that  emerged  from  our  data  in  terms  of  these  categories  of  assimilators,  with 
respect  to  the  stages  of  the  assimilation  process,  and  the  factors  that  influenced  this  process. 

Stages  in  the  Assimilation  Process  of  CASE  innovations 

Of  the  eleven  companies  we  examined  none  followed  exactly  the  nine  substage  process  of 
technological  innovation  assimilation,  outlined  in  Table  5.  Most  of  the  differences  occurred  in  the 
later  stages,  and  seemed  to  be  influenced  by  managers'  perceptions  of  the  role  to  be  played  by 
CASE  tools  in  their  organizations. 


2  It  is  estimated  that  only  some  2  percent  of  organizations  in  the  U.S.  have  purchased  CASE  tools,  and  that  only  40 
percent  of  the  purchasers  are  continuing  users  of  this  innovation  [Vitalari  1988]. 

3  We  decided  not  to  employ  Rogers  [1983]  label  "laggards"  for  this  final  group,  to  prevent  confusion  between  this 
categorization  of  assimilation  and  his  categorization  of  innovativeness,  and  also  to  avoid  the  unintended  pejorative 
connotation  of  the  "laggards"  label. 


Knowledge-Awareness  Stage: 

In  most  of  the  cases,  the  knowledge-awareness  stage  was  followed  as  outlined,  with  one  or  two 
senior  information  systems  managers  considering  and  discussing  the  viability  of  adopting  CASE 
tools  in  their  company.  Most  of  the  managers  appeared  to  learn  of  CASE  tools  from  the  trade  press 
and  their  contact  with  contemporaries  in  other  companies.  In  one  of  the  deliberators,  a  new 
information  systems  manager  was  hired  in  from  outside,  and  he  brought  with  him  knowledge  of 
and  interest  in  the  FEW  toolset.  This  boosted  the  assimilation  process  as  the  chief  advocate  of  the 
innovation  had  prior  experience  with  it,  and  could  speak  with  authority  about  its  likely  effects  and 
consequences. 

Evaluation-Choice  Stage: 

The  next  stage  was  typically  not  followed  as  outlined.  None  of  the  companies  undertook 
benchmarks  comparing  CASE  tools  with  their  current  development  practices.  In  only  two  of  the 
companies,  one  from  the  early  assimilators  and  one  from  the  deliberators  group,  was  a  financial 
evaluation  completed,  with  costs  and  benefits  formally  analyzed.  Some  respondents  cited  difficulty 
in  assessing  benefits  as  the  reason  for  not  pursuing  formal  feasibility  studies.  That  these 
respondents  did  not  also  find  costs  difficult  to  assess  reveals  a  lack  of  appreciation  for  the  potential 
impacts  of  CASE  tools,  an  issue  we  return  to  in  section  5.  This  underestimation  is  an  indicator  of 
the  general  finding  that  IS  managers  do  not  perceive  deployment  of  CASE  tools  as  a  significant 
technological  innovation,  certainly  not  significant  enough  to  warrant  a  formal  feasibility  analysis, 
the  mechanics  of  benefits  assessment  aside.  One  company  in  the  late  assimilator  group  had 
attempted  a  costs-benefits  analysis  primarily  for  symbolic  reasons  to  appease  senior  decision- 
makers. The  respondent  from  this  company  noted  that  the  costs  and  particularly  the  benefits  are  so 
difficult  to  calculate  that  the  exercise  was  "a  waste  of  time."  The  overwhelming  motivation  for 
implementing  CASE  tools  appears  to  be  the  quality  of  systems  development,  with  nine  of  the 
companies  citing  this  concern.  Given  the  difficulty  of  quantifying  the  notion  of  quality,  it  is  clear 
why  so  many  companies  felt  it  unnecessary  to  perform  a  financial  evaluation  of  their  CASE 
innovations. 

Functional  and  political-strategic  considerations  did,  however,  play  a  role  in  promoting  investment 
in  CASE  tools,  although  these  served  more  as  rationalizations  than  as  documentary  evidence  for 
the  need  to  innovate.  Managers  cited,  as  their  reasons  for  adopting  IEW,  concern  with  the  quality 
and  length  of  the  systems  development  effort,  the  productivity  of  systems  development  and 
maintenance  personnel,  and  the  desire  to  enforce  data  modeling  and  improve  data  management. 
None  of  these  rationales  for  adopting  CASE  tools  however,  were  formally  documented  or 

10 


quantified,  and  seemed  to  depend  less  on  rational  evaluation  than  on  dissatisfaction  with  the 
existing  state  of  affairs  in  systems  development  or  concern  about  the  future.  The  choice  to  invest  in 
CASE  tools  seemed  to  be  based  on  one  or  more  of  three  types  of  perceptions  of  CASE  tools:  (i)  as 
functionally  necessary  -  "...  to  reduce  the  amount  of  redundant  data  ...  to  bring  our  company  to  a 
shared  data  environment  that  met  the  needs  of  the  corporation";  (ii)  as  politically  important  for  the 
survival  of  the  information  systems  unit  -  "IS  management  believes  that  it  [CASE  tools]  is  a  critical 
success  factor;  that  we  need  to  automate  ourselves  to  stay  competitive.  There  are  a  lot  of  ways  we 
compete  with  outside  vendors  for  the  business  of  our  clients  within  the  company";  or  (iii)  as 
strategically  important  for  the  success  of  the  company  -  "...  all  we  have  is  information  [the 
company  provides  information  services  to  its  customers] ...  If  we  can't  change  these  systems  with 
quality,  that  is  do  it  right  and  do  it  fast,  if  we  can't  do  it  with  speed  and  quality,  someone  else  is 
going  to." 

Adoption-Implementation  Stage: 

Breakdowns  and  short-cuts  were  observed  in  the  third  and  final  stage  as  well.  First,  only  one  of 
the  companies,  an  early  assimilator,  has  fully  accepted  the  CASE  innovation,  and  has  started  to 
upgrade  their  version  of  the  IEW  toolset  with  an  expanded  version.  In  most  of  the  other 
companies,  the  process  of  assimilation  seems  to  be  stuck  in  an  extended  phase  of  trial  evaluation. 
Adopting  units  or  organizations  appear  to  be  equivocal  about  widespread  use  of  CASE  tools,  and 
have  tended  to  implement  IEW  in  only  a  few  projects,  or  only  one  division.  And  this  is  two  to 
three  years  after  acquiring  the  innovation.  Choice  of  pilot  project  emerged  as  a  key  decision,  with 
some  companies  choosing  a  critical  system  to  pilot,  reasoning  "The  pilot  project  has  to  prove  to  the 
organization  that  there  is  a  great  quality  improvement,  not  necessarily  just  improved  productivity  in 
a  pilot  project",  while  others  preferred  the  less  risky  but,  also  potentially,  less  informative  strategy 
of  piloting  small  and  simple  systems.  The  decision  to  pilot  a  critical  system  does  not  reflect  the 
degree  of  assimilation  of  the  company  (two  are  from  the  early  assimilator  group,  two  from  the 
deliberators  and  one  from  the  late  assimilators  groups),  but  may  reflect  managers'  individual  risk 
preferences,  or  their  views  of  the  importance  of  CASE  tools.  In  the  latter  case,  those  managers 
who  believe  in  the  strategic  importance  of  tools  are  anxious  to  test  them  on  major  projects,  while 
those  deploying  CASE  tools  for  more  conventional  reasons  adopt  them  incrementally,  starting  with 
limited,  routine  systems. 

An  important  phase  in  this  stage  that  emerged  from  the  data,  and  that  is  not  explicitly  covered  by 
Meyer  &  Goes'  [1988]  assimilation  model  (except  in  the  name  of  the  third  stage;  see  Table  5),  is 
that  of  implementation.  By  this  we  mean  the  decisions,  strategies,  and  activities  engaged  in  in 
order  to  put  the  innovation  into  routine  use  in  the  organization.  As  research  on  information  systems 

11 


implementation  has  shown  [Ginzberg  1979;  Lucas  1981;  Markus  1983;  Rousseau  1989] 
introducing  new  information  technology  into  an  organization  is  a  nontrivial  endeavor,  permitting 
alternative  strategies,  involving  multiple  constituencies,  and  generating  conflicting  perspectives. 

Rogers  [1983:364-365]  in  his  original  model  of  the  assimilation  process  does,  however,  include 
implementation,  suggesting  it  is  constituted  by  the  three  phases  of:  restructuring,  clarifying,  and 
routinizing.  Restructuring  involves  the  modification  of  the  innovation  to  fit  the  organization,  and 
the  reciprocal  change  in  the  organization  structure  to  accommodate  the  innovation.  During 
clarification,  the  meaning  of  the  innovation  becomes  clearer  to  the  organization  members,  and 
organizational  practices  stabilize  around  it  as  it  achieves  wider  use.  Finally  the  innovation  is 
routinized,  and  it  becomes  fully  integrated  into  the  organization,  losing  its  distinct  identity.  This 
last  phase  of  routinization  resembles  Meyer  &  Goes'  [1988]  substage  of  acceptance.  The  eleven 
companies  we  studied  had  not  moved  through  all  these  three  phases,  and  the  most  significant 
implementation  phase  appeared  to  be  restructuring.  The  final  substages  of  the  third  assimilation 
stage,  acceptance  and  expansion,  have  not  yet  been  experienced  by  any  company.  One  company 
appears  to  have  moved  into  a  form  of  acceptance  phase  by  mandating  the  use  of  EEW  on  all  new 
projects.  However  it  is  not  clear  how  much  acceptance  the  innovation  has  in  reality,  and  only  time 
will  reveal  whether  the  innovation  persists,  becoming  routinized  and  commonplace,  or  whether  it 
is  discontinued  through  not  having  sufficient  support  from  organizational  members. 

Most  of  the  eleven  companies  have  embarked  on  some  restructuring,  both  of  the  CASE  tools  and 
of  their  own  organizations.  All  of  the  companies  reported  customizing  the  methodology, 
information  engineering  (IE),  that  guides  the  IEW  toolset.  In  the  opinion  of  the  respondents,  there 
were  no  "off-the-shelf  IE  methodologies  that  provided  adequate  depth  and  coverage  for  the  entire 
systems  development  and  maintenance  life  cycle.  As  a  result  most  of  the  companies  had  developed 
their  own  set  of  standards,  procedures,  and  plans,  that  accompanied  their  use  of  IEW  on  projects. 
One  organization,  in  the  late  assimilators  group,  had  adapted  its  prior  systems  development 
methodology  -  based  on  Yourdon  &  Constantine's  [1979]  structured  systems  development  -  to 
play  this  role.  The  respondents  also  reported  that  reciprocal,  structural  and  procedural  changes  had 
been  initiated  to  accommodate  the  deployment  of  CASE  tools  in  their  companies.  Five  of  the 
companies  (one  early  assimilator,  three  deliberators,  and  one  late  assimilator)  have  reorganized 
their  systems  development  units,  with  two  companies  (both  deliberators)  contemplating 
restructuring  in  the  near  future.  The  primary  reorganization  involves  the  concentration  of  personnel 
interacting  with  the  CASE  tools,  and  their  distinction  from  other  systems  personnel  by  the 
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formation  of  a  new  structural  unit.4  For  example,  some  companies  have  grouped  the  applications 
developers  who  use  EEW  together,  while  others  have  grouped  the  personnel  who  support  and  train 
on  EW  to  form  a  staff  unit. 

We  found  it  interesting  that  of  the  seven  companies  reporting  current  or  proposed  organizational 
changes  to  accommodate  CASE  tools,  early  assimilators  were  under-represented.5  Early 
assimilator  companies  have  progressed  the  quickest  through  the  assimilation  process  yet  they  seem 
furthest  behind  in  accommodating  to  CASE  tools.  It  is  possible  that  these  early  assimilators  are  so 
intent  on  implementing  the  innovation  and  getting  widespread  acceptance  that  they  spend  less  time 
contemplating  organizational  change.  It  is  feasible  that  a  company  or  unit  that  is  assimilating  an 
innovation  more  slowly  and  deliberately,  has  the  luxury  to  reflect  on  the  organizational  adjustments 
needed  to  integrate  the  innovation.  From  discussions  with  the  respondents  it  appears  that  the 
deliberate  action  of  information  systems  managers,  in  structuring  the  deployment  of  CASE  tools, 
plays  an  important  role  in  enacting  their  assimilation  and  shaping  people's  expectations. 

The  above  has  examined  an  idealized  model  of  the  innovation  assimilation  process  in  the  context  of 
eleven  companies  attempting  to  implement  the  same  innovation,  the  IEW  CASE  tools.  The  model 
appears  to  be  useful  in  identifying  disjunctures  and  differences,  and  we  see  that  in  the  assimilation 
of  CASE  innovations  more  time  and  attention  is  focused  on  the  implementation  stage,  while  less 
energy  and  resources  are  expended  on  formal  evaluation.  The  appropriateness  of  this  process  is 
addressed  in  section  5. 

Factors  influencing  the  Assimilation  of  CASE  Innovations 

The  innovation  literature  has  identified  a  number  of  organizational  and  technological  factors  that 
influence  the  process  of  innovation  assimilation.  In  this  section  we  examine  those  factors  that 
emerged  from  the  data  obtained  in  our  study.  In  discussing  the  factors  that  are  associated  with 
implementing  CASE  tools,  we  will  employ  the  model  of  factors  proposed  by  Meyer  &  Goes 
[1988].  Hence  we  examine  the  factors  in  terms  of:  attributes  of  innovations,  attributes  of 
organizational  contexts,  and  attributes  of  the  interaction  between  innovations  and  contexts. 

Attributes  of  CASE  Innovations: 

Meyer  &  Goes  first  identified  the  risk  associated  with  use  of  the  innovation  as  a  negative  influence 

on  the  assimilation  process.  None  of  the  companies  we  studied  considered  this  factor  as  significant 


4  In  some  organizations  such  groups  have  been  labeled  "Development  Centers." 

5  One  of  two  late  assimilators,  five  out  of  six  deliberate  assimilators,  and  only  one  of  the  three  early  assimilators 
had  insututed  or  were  about  to  iniuate  organizational  changes  in  response  to  CASE  tools. 
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in  their  adoption  behavior,  although  one  company  [an  early  assimilator  and  provider  of  information 
services]  was  concerned  with  not  adopting  CASE  tools  for  fear  of  losing  customers.  Interestingly 
the  risk  of  decreasing  the  morale  of  systems  developers  as  a  consequence  of  CASE  tools  was  not 
considered  a  significant  attribute  of  the  innovation,  despite  the  dissatisfaction  of  many  information 
systems  personnel  to  CASE  tools  (see  the  discussion  of  IS  personnel  below).  It  appears,  at  least 
for  the  managers  we  interviewed,  that  dissatisfaction  by  the  systems  development  workforce  is 
considered  a  personnel  problem,  and  hence  an  attribute  of  the  organizational  context,  rather  than 
something  associated  with  or  engendered  by  the  technology. 

The  second  attribute  articulated  by  Meyer  &  Goes  [1988],  skill,  was  invoked  by  many  managers 
as  a  relevant  attribute  of  CASE  tools,  in  particular  the  nature  and  amount  of  training  that  systems 
developers  and  users  need  before  they  can  interact  usefully  with  IEW.  Meyer  &  Goes  [1988] 
found  that  those  innovations  that  required  relatively  little  skill  and  training  were  more  readily 
assimilated  than  other  innovations.  In  our  study  we  found  concern  with  the  lack  of  available 
training  by  outside  vendors.  Those  companies  that  established  their  own  internal  training  programs 
appear  to  to  be  more  satisfied  with  the  rate  and  manner  of  transferring  IEW  skills  to  their 
personnel.  Providing  in-house  training  allows  companies  to  retain  control  over  the  content,  timing, 
and  frequency  of  courses.  It  also  allows  them  to  tailor  training  to  their  customized  IE 
methodologies,  and  to  particular  project  teams.  An  interesting  result  that  emerged  was  that  the  best 
education  results  were  obtained  from  training  entire  project  teams  together.  Such  group  training 
apparently  allows  educators  to  target  project-specific  issues,  and  permits  participants  to  learn  about 
CASE  tools  in  a  relevant  context,  in  contrast  to  being  exposed  to  the  innovation  abstractly  or  with 
reference  to  some  minor  problem. 

The  final  innovation  attribute  identified  by  Meyer  &  Goes  [1988],  observability,  played  an 
important  role  in  the  companies  we  studied.  We  interpreted  observability  in  this  context  to  mean 
the  impact  of  CASE  tools  on  the  performance  and  quality  of  systems  development  -  the  targets  of 
most  systems  development  improvement  efforts.  Nine  of  the  companies  reported  improvements  in 
quality  of  systems  development,  particularly  user  satisfaction,  while  only  two  noted  improvements 
in  performance.  None  of  the  companies  had  instituted  measures  of  quality  or  user  satisfaction,  and 
only  one  was  tracking  systems  development  productivity  (via  function  point  measures),  so  most  of 
the  impact  assessments  were  based  on  perceptions.  However  it  is  often  the  subjective  impressions 
rather  than  the  objective  results  of  an  innovation  that  influence  action.  This  phenomenon  seems  to 
be  operating  in  the  companies  we  studied,  for  despite  the  lack  of  measurable  improvements 
following  early  experiences  with  CASE  tools,  the  motivation  to  continue  using  this  innovation  was 
high  across  all  assimilator  groups. 
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Attributes  of  the  Organizational  Context: 

Some  of  Meyer  &  Goes  [1988]  organizational  context  factors  were  specific  to  their  study  of 
hospitals,  and  hence  will  not  be  considered  here.  One  of  the  criteria  for  selecting  the  organizations 
in  our  sample  was  size,  so  we  could  not  consider  its  role  in  the  assimilation  process,  although  this 
may  be  an  interesting  variable  for  future  research.  Some  other  factors  indicated  by  Meyer  &  Goes' 
[1988]  research  such  as  market  strategy,  complexity  of  product/service,  and  personnel  education 
and  tenure  may  also  be  appropriate.  Because  information  on  these  attributes  or  their  surrogates  was 
unavailable  in  our  study,  we  had  to  exclude  them  from  consideration.  However,  we  speculate  on 
why  and  how  these  attribtues  may  be  significant  in  section  6. 

The  following  discussion  refers  to  the  particular  organizational  context  within  which  CASE  tools 
are  implemented.  We  examined  the  data  to  determine  the  significance  of  a  number  of  possible 
attributes  that  characterize  the  context  around  systems  development,  such  as  IS  department 
organization  (centralized,  decentralized,  or  mixed),  size  of  IS  department,  type  of  information 
processing  (transactions,  control,  decision  support,  etc.),  but  none  of  these  appeared  in  our  dataset 
to  be  significant  influences  of  the  process  of  CASE  tools  assimilation.  Two  attributes  however,  did 
emerge  as  key  organizational  influences.  The  first  we  term  orientation  of  information 
systems  personnel.  Prior  research  [Orlikowski  1988]  has  shown  that  systems  development 
personnel  respond  differentially  to  the  deployment  of  CASE  tools  depending  on  their  orientations 
to  their  work  and  their  careers.  Personnel  having  a  process  orientation  to  systems  development 
work,  tend  to  be  more  technically  inclined  and  tend  to  have  data  processing  career  aspirations. 
They  are  much  more  resistant  to  CASE  innovations,  perceiving  these  as  threats  to  their  skills, 
status,  job  security  and  work  autonomy.  Results  oriented  systems  developers  tend  to  have  more 
functional  interests  and  career  aspirations  that  are  not  localized  in  the  data  processing  occupation. 
They  have  a  closer  affinity  to  users  and  are  less  threatened  by  CASE  innovations  as  the  skills  and 
status  potentially  displaced  are  not  highly  valued.  The  findings  from  this  study  support  these 
expectations.  More  traditional  (usually  implying  older  or  more  tenured)  systems  development 
personnel  or  more  technical  personnel  were  reported  to  be  reluctant  to  utilize  CASE  tools,  while 
those  personnel  being  more  analysis  oriented  were  eager  to  try  them  out.  Further,  all  systems 
developers  were  found  to  be  somewhat  resentful  of  the  increased  role  played  by  users  in  projects. 
As  we  discuss  below,  the  particular  CASE  tool  we  examined,  IEW,  facilitates  greater  user 
participation  in  and  responsibility  for  the  front-end  of  projects.  This  shift  in  control  is  typically 
problematic  for  the  systems  developers  to  adjust  to. 
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A  surprising  result  was  the  degTee  of  reluctance  of  many  systems  development  managers  to 
adopting  CASE  tools.  This  led  to  the  second  organizational  context  factor,  which  we  term 
territorialism  of  the  information  systems  department.  By  this  we  mean  the  extent  to 
which  systems  developers  and  managers  are  protective  of  their  traditional  areas  of  control.  Prior 
research  [Orlikowski  1988]  had  found  project  managers  to  be  sufficiently  concerned  with 
efficiency,  productivity  and  "getting  the  system  out  the  door"  to  be  enthusiastic  supporters  of 
CASE  tools.  However  some  of  the  companies  we  examined  were  experiencing  resistance  to  the 
innovation  from  management  ranks.  One  respondent  explained,  "The  DP  [Data  Processing] 
management  has  really  been  the  group  that  has  not  reacted  to  it  [TEW]  with  open  arms.  You've  got 
a  lot  of  older  people  who  have  developed  systems  for  years,  and  we  think  we  know  how  to  do  it. 
Just  like  our  users,  we  resist  change."  It  is  likely  that  the  discrepancy  between  this  finding  and  that 
of  the  prior  research  rests  on  the  difference  in  companies  examined,  with  the  latter  focusing  only 
on  software  consulting  projects,  where  project  managers  may  be  expected  to  be  less  tied  to 
traditional  skills  and  familiar  ways  of  doing  things.  Resistance  to  the  CASE  innovation  by  IS 
managers  is  likely  to  restrict  the  assimilation  process,  for  they  are  typically  the  key  operational 
decision-makers  when  it  comes  to  initiating  and  executing  projects.  Non-cooperation  from  these 
players  may  well  thwart  the  entire  innovation  assimilation  effort. 

Attributes  of  the  Interaction  between  CASE  Innovations  and  Organizational  Context: 
Both  of  Meyer  &  Goes'  [1988]  factors  in  this  category  proved  relevant  in  our  study.  In  addition, 
we  believe  two  others  are  also  significant.  First,  the  Meyer  &  Goes'  attribute  of  compatibility,  by 
which  they  mean  the  congruence  of  the  technology  to  the  existing  pattern  of  work  and 
specialization.  We  interpreted  this  to  refer  to  the  role  of  systems  development  methodology,  and 
examined  how  the  methodology-in-use  in  the  IS  unit  is  compatible  with  that  of  the  CASE  tools. 
Methodology  is  critical  to  the  use  of  the  CASE  innovation  for  it  mediates  between  the  division  of 
labor  in  the  systems  development  process  and  the  automated  tools  that  facilitate  task  execution. 
Thus  we  examined  the  extent  to  which  companies  had  adapted  their  existing  pattern  of  systems 
development  work,  as  represented  by  their  methodology-in-use,  to  conform  to  that  informing  the 
CASE  tools,  in  the  case  of  IEW,  the  IE  methodology.  We  found  that  all  the  early  assimilators  and 
all  but  one  of  the  deliberators  had  specifically  adopted  the  IE  methodology  either  before  or  at  the 
same  time  as  the  acquisition  of  IEW.  For  these  eight  companies  a  compatibility  between  the 
methodology-in-use  and  that  inherent  in  the  CASE  tools  had  been  accomplished.  This  provided 
advantages  of  consistency  in  terminology,  standards,  concepts,  learning  and  familiarity  of  users 
and  developers.  Both  of  the  late  assimilators  and  one  deliberator  had  deliberately  chosen  not  to 
adopt  the  IE  methodology,  preferring  to  retain  their  own  traditional  (process-oriented) 
methodologies.  Maintaining  two  different  methodologies  (even  though  one  is  more  implicit,  being 
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embodied  in  the  CASE  tools)  adds  a  conceptual  and  logistic  burden  on  systems  development. 
Inconsistencies  in  approaches,  timing,  milestones,  deliverables,  standards,  terminology,  and 
assumptions  need  to  be  resolved,  translated  and  communicated.  This  takes  time,  energy,  and 
coordination. 

Meyer  &  Goes'  [1988]  second  interaction  factor,  CEO  advocacy,  is  similar  to  what  we  termed 
senior  management  advocacy.6  This  factor  appeared  consistently  in  the  data  as  an  important 
facilitator  of  the  CASE  tools  assimilation  process  in  all  of  the  companies  we  examined.  By  senior 
management  we  mean  both  senior  functional  or  user  managers  and  the  IS  director.  By  advocacy, 
we  follow  Meyer  &  Goes  [1988:910]  in  referring  to  (i)  the  extent  to  which  senior  managers 
personally  support  the  acquisition  of  CASE  tools  and  (ii)  the  extent  to  which  senior  managers  exert 
influence  and  expend  resources  during  the  assimilation  process.  Regardless  of  who  made  the  initial 
decision  to  acquire  the  CASE  tools,  those  companies  reporting  greater  success  in  diffusing  the 
CASE  tools  (all  three  early  assimilators,  and  one  deliberator)  reported  exceptionally  high  degrees 
of  senior  management  involvement  and  commitment  to  the  innovation. 

Two  other  factors  emerged  as  relevant  in  the  interaction  between  organizational  context  and  the 
CASE  innovation.  One  of  these  is  highly  predicted  by  the  implementation  literature,  user 
involvement,  while  the  other  is  implementation  strategy.  In  this  study,  user  involvement 
emerged  as  the  most  consistent  finding  across  all  the  companies,  whatever  their  state  of  CASE 
assimilation.  Given  this  result,  it  is  interesting  to  note  that  the  role  of  the  user  or  client  in  the 
assimilation  process  has  warranted  little  attention  from  the  general  innovation  literature.  All 
companies  in  this  study  reported  a  significant  increase  in  the  extent  of  user  involvement  in  systems 
development  following  the  use  of  CASE  tools.  More  interesting  is  the  finding  that  this  user 
involvement  augments  the  assimilation  of  CASE  tools,  because  users  begin  to  pressure  the  IS 
departments  for  greater  use  of  the  IEW  CASE  tools.  Indeed,  in  some  companies  senior  users  have 
started  to  be  project  managers  on  those  projects  employing  CASE  tools. 

Users  appear  to  be  highly  appreciative  of  the  CASE  tools'  requirements  determination  phase, 
known  as  Business  Area  Analysis  (BAA)  in  IE  parlance.  This  phase  is  a  conceptual,  highly 
functional  analysis  of  the  business  requirements  of  a  particular  system,  in  terms  that  are  easily 
understood  by  the  users.  Users  reported  that  the  BAA  process  had  taken  much  of  the  mystery  out 
of  requirements  definition,  and  it  allowed  an  integrated  view  of  the  entire  system  before 


6  We  have  deliberately  adopted  Meyer  &  Goes'  [1988]  term  "advocacy"  rather  than  the  more  common  one  of 
"commitment"  used  in  the  IS  literature,  as  it  captures  more  of  the  championing  activity  required  of  senior 
managers,  than  does  the  more  passive  endorsement  implied  by  "commitment" 
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development  began.  Further  users  reported  increased  completeness  of  requirements,  decreased 
ambiguity,  more  comprehensive  documentation,  and  greater  enthusiasm.  A  user  noted  that  the 
process  involves  the  users  in  the  front  end  and  forces  them  to  address  the  business  problems, 
while  keeping  the  systems  developers  in  focus  about  what  the  business  needs  are.  A  critical  benefit 
of  greater  user  involvement  is  that  it  provides  users  with  a  level  of  control  over  systems 
development  they  have  typically  not  experienced  before.  One  user  commented  about  BAA:  "It  was 
the  first  time  in  my  experience  at  [name  of  company],  and  that's  been  twenty-six  years  in  and  out 
of  data  processing,  that  the  users  had  the  first  say  so  as  to  how  they  wanted  the  system  designed." 
However  this  shift  in  control  has  not  always  been  well  received  by  the  system  developers  or  their 
managers.  One  company,  an  early  assimilator,  was  experiencing  negative  reactions  from  IS 
managers  about  the  fast  pace  of  development  fueled  by  the  CASE  tools  and  the  user  demand.  One 
such  manager  explained  the  resentment:  "We  think  we  know  better  than  the  users  do  as  to  what 
they  need.  We  don't  like  all  this  user  involvement.  We  like  to  protect  our  territory.  We  kind  of 
liked  it  when  there  was  a  lot  of  mystery." 

As  users  appreciate  BAA  more,  they  become  more  insistent  about  the  use  of  CASE  tools  on  their 
systems  development  efforts,  hence  pressuring  the  IS  department  to  speed  up  their  assimilation  of 
the  CASE  innovation.  However,  this  influence  is  not  only  one-directional,  for  often  the  IS 
directors  play  an  important  role  in  ensuring  user  involvement,  hence  facilitating  user  participation 
in  and  understanding  of  the  innovation.  One  IS  manager,  responsible  for  integrating  the  CASE 
tools  in  his  company  explained:  "If  they  [the  users]  are  not  involved,  there  is  no  project.  If  they 
don't  have  time  to  put  a  good  person  on  the  project,  the  project  is  cancelled.  We  have  cancelled  I 
don't  know  how  many  projects,  but  it  is  not  unreasonable  to  see  that  a  project  is  cancelled  because 
clients  don't  take  interest  or  don't  have  the  time." 

As  indicated  above,  the  implementation  stage  is  not  treated  in  any  depth  by  Meyer  &  Goes  [1988] 
or  Rogers  [1983],  and  neither  is  the  particular  strategy  that  companies  follow  during 
implementation.  This  attribute  of  the  implementation  stage  however,  proved  to  be  a  dominant 
aspect  of  the  process  followed  by  companies  in  assimilating  CASE  innovations.  In  particular,  the 
presence  of  an  explicit  and  phased  implementation  strategy  appears  to  facilitate  the  diffusion  of  the 
CASE  tools  through  systems  development  operations.  One  of  the  companies,  a  late  assimilator, 
had  no  explicit  implementation  strategy,  which  may  account  for  some  of  the  delay  in  getting  a 
production  system  completed.  The  rest  of  the  companies  all  appeared  to  have  explicit 
implementation  strategies.  Three  different  implementation  strategies  were  identified  among 
the  ten  companies.  One  we  refer  to  as  the  vertically  phased  implementation  strategy,  which  is 
premised  on  implementing  the  CASE  tools  incrementally  via  individual  projects.  Another  strategy, 
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which  we  refer  to  as  the  horizontally  phased  implementation  strategy,  is  premised  on  implementing 
the  CASE  tools  incrementally  stage  by  stage,  across  the  development  life  cycle  of  all  projects.  The 
final  strategy  we  label  the  combination  phased  implementation  strategy,  and  this  is  premised  on 
diffusing  the  CASE  tools  in  two  directions:  incrementally  project  by  project  (as  in  the  vertically 
phased  strategy),  and  laterally,  stage  by  stage,  (as  in  the  horizontally  phased  strategy).  All  these 
strategies  appear  to  have  merit  in  that  they  structure  the  diffusion  of  the  innovation,  generating  a 
decomposition  logic  and  time-based  plan  to  organize  the  implementation  activities.  We  suggest  that 
the  strategies  need  not  be  followed  to  the  letter,  as  their  value  lies  in  their  symbolic  and  organizing 
function  rather  than  in  their  detailed  prescriptions. 

The  vertically  phased  strategy  was  by  far  the  most  prevalent,  detected  among  eight  of  the 
companies.  For  each  project  initiated,  the  CASE  tools  are  used  during  the  entire  life  cycle.  The 
companies  adopting  this  strategy  started  with  one  or  two  pilot  projects  to  demonstrate  viability  of 
the  CASE  approach,  then  followed  this  with  the  vertically  phased  strategy  whereby  an  increasing 
proportion  of  the  systems  development  projects  use  CASE  until  it  becomes  the  standard  for  all 
systems  development  projects  (see  Figure  1).  One  company,  an  early  assimilator,  is  already  at  the 
point  where  100  percent  of  its  new  development  projects  use  CASE  tools,  while  another  early 
assimilator  is  at  the  70  percent  mark.  The  rest  of  the  companies  we  studied  displayed  much  lower 
rates  of  diffusion. 

An  advantage  of  the  vertically  phased  implementation  strategy  is  that  companies  can  exploit  the 
learning  curve,  making  adjustments  to  their  methodology  and  development  standards  and 
procedures  as  a  result  of  lessons  learnt  on  prior  CASE  tools  projects.  Another  advantage  is  the 
development  of  critical  mass.  That  is,  system  developers  gaining  expertise  with  the  CASE  tools  on 
the  first  projects  can  be  used  on  subsequent  projects.  This  allows  project  teams  to  leverage  the 
experience  they  gained  on  prior  development  efforts. 

The  horizontally  phased  strategy  was  evident  in  only  one  company,  a  late  assimilator.  Here  the 
CASE  tools  are  introduced  functionally,  first  the  analysis  workbench  across  projects,  then  the 
design  workbench  across  projects,  and  so  on  (see  Figure  1).  CASE  tools  are  thus  not  being 
introduced  in  an  integrated  fashion,  rather  particular  tools  are  being  brought  in  one  by  one  to  be 
used  in  combination  with  existing  manual  methods.  Eventually  all  the  phase  tools  will  have  been 
implemented  and  the  advantages  of  an  integrated  toolset  can  be  derived.  The  company  which  has 
adopted  this  strategy  is  one  of  the  late  assimilators.  Progress  has  been  slow,  and  no  production 
system  has  yet  been  built  with  CASE  tools. 
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Figure  1:  Implementation  Strategies 
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The  advantages  of  the  horizontally  phased  strategy  is  that  it  allows  the  implementation  of  the 
innovation  in  conceptual  chunks.  Rather  than  inundating  system  developers  with  a  whole  new 
approach  to  the  entire  development  life  cycle,  this  approach  allows  developers  to  gain  expertise  and 
familiarity  with  one  piece  of  the  innovation  at  a  time.  Only  when  all  system  developers  are 
experienced  with  a  tool,  is  the  next  one  implemented.  The  other  advantage  of  this  approach  is  that 
it  diffuses  the  innovation  to  all  developers  at  the  same  time.  It  does  not  create  an  elite  group  of 
system  developers  who  gain  exclusive  experience  with  CASE  tools  and  then  tend  to  dominate 
automated  development  projects.  The  "crack  team"  approach  to  innovation  diffusion  is  efficient,  in 
that  the  expertise  and  experience  of  a  few  developers,  is  highly  leveraged.  It  may  however 
encourage  resentment  and  resistance  from  the  rest  of  the  developers  who  get  left  with  the 
maintenance  work,  and  who  perceive  themselves  as  no  longer  in  the  mainstream  of  development 
activities.  The  horizontally  phased  strategy  can  help  to  avoid  this  potential  human  resource 
problem. 

The  combination  phased  strategy  was  observed  at  one  company,  an  early  assimilator.  In  this 
strategy  the  requirements  definition  stage  of  the  EE  methodology  (BAA)  is  used  for  all  projects, 
whether  these  will  use  the  EW  tools  during  development  or  not.  Thus  not  only  are  individual 
projects  incrementally  adopting  the  CASE  tools  over  time,  but  all  projects  are  adopting  one  aspect 
of  the  CASE  innovation,  the  BAA,  for  the  up-front  requirements  determination  activities. 

The  combination  phased  strategy  thus  gains  the  advantages  of  the  vertically  phased  strategy,  as 
well  as  that  of  the  horizontally  phased  strategy.  It  greatly  increases  user  enthusiasm  and 
involvement,  for  the  BAA  phase  is  the  most  visible  and  most  relevant  to  the  users.  It  increases 
pressure  from  users  to  diffuse  the  CASE  tools,  for  as  the  company  using  this  strategy  reported,  the 
users  get  so  excited  by  the  BAA  process  that  they  start  spreading  positive  information  about  the 
innovation  throughout  the  company.  The  company  has  completed  approximately  70  BAA's  in  the 
past  two  years,  while  still  making  the  same  relative  progress  as  other  early  assimilators  in  the 
implementation  of  CASE  tools  in  the  entire  development  life  cycle. 

4.3  Summary  of  Results 

Based  on  the  detailed  findings  discussed  above,  the  process  of  assimilation  of  CASE  innovations 
can  be  seen  to  mirror  that  of  other  innovations,  except  with  different  emphases.  Assimilation  of 
CASE  tools  appears  to  involve  more  time  in  the  implementation  stage,  with  less  formal  evaluation. 
While  this  is  what  companies  are  doing  it  is  not  clear  that  this  necessarily  is  the  appropriate 
procedure.  In  the  following  section  we  will  argue  that  companies  may  be  underestimating  the 
potential  impact  of  their  CASE  innovation,  and  that  more  careful  evaluation  and  weighing  of 
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consequences  may  be  in  order.  Table  6  summarizes  the  factors  that  emerged  from  our  case  studies 
as  important  attributes  influencing  the  assimilation  process  of  CASE  innovations.  We  emphasize 
that  this  is  a  preliminary  model,  whose  elaboration  and  verification  awaits  future  research. 

Table  6:  Factors  influencing  the  Assimilation  of  CASE  Innovations 

[adapted  from  Meyer  &  Goes  1988:908] 


ATTRIBUTES  OF  CASE  INNOVATIONS 
( - )     Skill/Training:  Extent  of  skill  or  specialized  training  required. 
( + )    Observability:  Extent  of  perceived  impact  on  systems  development  quality 
and  performance. 

ATTRIBUTES  OF  ORGANIZATIONAL  CONTEXT 

(-)    Orientation  of  IS  Personnel:  Extent  to  which  systems  developers  are 
process-oriented  and  commined  to  data  processing  careers. 

(-)    Territorialism  of  IS  Department:  Extent  to  which  systems  developers  and 
managers  are  protective  of  their  traditional  areas  of  control. 

CASE  INNOVATION-CONTEXT  ATTRIBUTES 

(  +  )    Senior  Management  Advocacy:  Extent  of  senior  managers  influence, 
personal  support,  and  commitment  of  resources. 

( + )    Methodology:  Extent  to  which  the  methodology-in-use  is  consistent  with 
that  inherent  in  the  CASE  tools. 

(  +  )    User  Involvement:  Extent  to  which  users  are  involved  and  directing 
systems  development  projects  utilizing  CASE  tools. 

(  + )    Implementation  Strategy:  Extent  to  which  an  explicit  and  phased 
implementation  strategy  is  employed. 


5 .  IMPLICATIONS  OF  FINDINGS  AND  RECOMMENDATIONS 

In  this  section  we  attempt  to  translate  some  of  the  specific  findings  into  more  general  terms,  and 
propose  some  of  the  implications  of  our  study  for  practice.  We  caution  that  these  interpretations  are 
tentative  and  based  on  our  exploratory  analysis  of  data  from  a  limited  sample.  The  implications  are 
in  two  parts,  the  first  set  refer  to  the  assimilation  process  itself  and  are  more  general,  while  the 
second  refer  to  the  factors  that  may  influence  the  success  of  the  process  and  are  more  specific  to 
particular  organizational  contexts. 
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5.1  Recommendations  on  the  CASE  Tools  Assimilation  Process 

In  the  discussion  of  results  we  noted  that  in  distinction  to  other  innovation  processes,  the  process 
followed  by  companies  assimilating  CASE  tools  seems  to  be  focused  on  implementation  with  less 
attention  being  paid  to  the  evaluation  phase.  Just  as  the  systems  development  community  is 
beginning  to  accept  the  need  to  spend  more  time  and  energy  on  the  front-end  aspects  of  systems, 
so  we  recommend  that  potential  adopters  of  CASE  tools  spend  more  time  up-front  evaluating  the 
tools,  determining  their  compatibility  with  existing  methodological,  structural  and  cultural 
characteristics  of  the  organization.  As  a  major  innovation,  and  as  this  study  has  shown,  CASE 
tools  can  and  do  interact  with  all  these  dimensions.  Thus  we  suggest  that  CASE  tools  be  treated  as 
a  major  information  system  whose  successful  implementation  will  need  careful  justification, 
planning,  user  involvement  and  training. 

We  suggest  that  the  real  intended  and  unintended  consequences  of  integrated  CASE  tools  are 
sufficiently  substantial  that  treating  them  as  significant  organizational  interventions  is  warranted  in 
most  cases.  CASE  tools  are  premised  on  the  automation  of  systems  development  activities;  their 
intention  is  to  substantially  alter  systems  development  and  maintenance  processes  [Norman  & 
Nunamaker  1988;  Orlikowski  1988].  Ignoring  their  innovative  aspects  ignores  their  very  essence. 
Little  attention  seems  to  be  paid  to  the  costs  and  benefits  of  CASE  tools.  Difficulty  in  quantifying 
them  should  not  preclude  considering  them  and  carefully  weighing  their  advantages  and 
disadvantages  within  the  particular  organizational  context.  Many  of  the  companies  studied  seemed 
unaware  of  the  many  intangible  costs  that  are  often  associated  with  CASE  tools.  The  costs  are  not 
only  those  of  purchasing  the  software,  developing  training  programs,  and  educating  all  the 
systems  developers.  There  are  also  organizational  costs  such  as  restructuring  the  IS  organization: 
possible  declining  morale  of  systems  developers  who  may  feel  threatened  and  alienated  by  CASE 
tools;  changing  career  paths  and  evaluation  mechanisms  to  accommodate  changed  jobs  and 
expectations  of  systems  developers;  and  introducing  a  new  methodology  and  new  standards  to 
ensure  compatibility  with  the  underlying  philosophy  of  the  CASE  toolset.  Our  general  process 
recommendation  is  that  the  activities  of  evaluation  be  taken  more  seriously,  and  that  managers 
contemplating  investing  in  CASE  tools  spend  time  carefully  evaluating  the  particular  factors  in  their 
organizations  that  may  facilitate  or  constrain  the  CASE  implementation  process  (see  below). 

We  also  recommend  that  companies  consider  organizational  restructuring  to  accomodate  the  CASE 
tools.  The  accommodation  of  organizations  to  an  innovation  has  significant  benefits  for  a  number 
of  reasons.  It  expedites  the  introduction  and  use  of  the  CASE  tools  by  structurally  concentrating 
expertise,  committing  resources,  and  facilitating  assistance  and  training.  Further,  it  allows  the 
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organization  to  establish  appropriate  policies,  standards,  and  practices,  hence  smoothing  the 
assimilation  of  the  innovation  into  the  organization.  This  procedural  accommodation,  while 
instrumental,  is  also  useful  motivationally,  forcing  deliberation  on  how  the  innovation  will  be 
employed,  and  focusing  energy  and  attention  on  its  potential  use  and  consequences.  Finally,  and 
possibly  most  significantly,  it  is  useful  symbolically,  for  it  sends  a  powerful  message  to 
organizational  members  that  this  innovation  is  sufficiently  significant  that  it  warrants  modifying  the 
organization  to  utilize  it.  The  innovation  is  given  credibility  and  legitimacy.  We  suspect  that  there  is 
a  relationship  between  organizational  accommodation  to  the  innovation  and  "success"  of  the 
assimilation  process.  Success  in  this  regard  is  understood  to  be  more  than  merely  quick 
assimilation,  for  speedy  innovation  can  bring  disruption,  insecurity,  and  ambiguity  if  these  are  not 
tempered  by  structural  alterations.  In  this  exploratory  study  it  was  not  possible  to  determine  the 
"success"  of  CASE  tools  assimilation,  and  the  role  of  organizational  restructuring  in  facilitating 
this.  It  is,  however,  an  important  topic  for  future  research. 

5.2  Recommendations  on  Factors  that  Influence  the  Assimilation  Process 

In  section  4.2  we  identified  and  discussed  eight  factors  (presented  in  Table  6)  that  were  found  in 
our  study  to  influence,  either  positively  or  negatively,  the  process  of  assimilating  CASE  tools  in 
organizations.  We  now  re-examine  these  factors  more  practically,  in  terms  of  how  they  can  be 
manipulated  to  obtain  a  desired  assimilation  result.  In  our  discussion  we  argue  that  of  the  eight 
factors  identified  above,  six  are  critical  to  the  assimilation  process.  The  extent  to  which  each  of 
these  is  critical  within  a  particular  company  varies,  of  course,  as  different  factors  will  be  more  or 
less  critical  in  different  organizational  contexts. 

Thus,  before  an  organization  can  perform  an  effective  evaluation  of  CASE  tools,  a  careful 
assessment  of  the  organizational  context  and  potential  CASE  tools  are  in  order.  Managers  need  to 
have  a  good  sense  of  the  conditions  under  which  CASE  tools  will  be  deployed,  and  the 
circumstances  within  which  they  will  operate,  to  be  able  to  assess  the  potential  success  or  impact 
of  CASE  tools  in  their  organization.  Having  understood  the  organizational  conditions,  practitioners 
should  assess  which  of  the  factors  critical  in  their  context  can  be  engineered  to  create  a  conducive 
environment  for  the  assimilation  of  CASE  tools. 

Each  of  the  factors  can  be  understood  to  either  promote,  constrain  or  be  neutral  to  the  success  of  a 
CASE  tools  assimilation  process.  For  example,  we  argue  that  compatibility  between  the  systems 
development  methodology  and  that  of  the  tools  can  facilitate  the  assimilation  process,  while 
incompatibility  appears  to  be  neutral  as  far  as  success  is  concerned.  Other  factors  however,  appear 
to  operate  in  opposing  ways,  that  is,  either  promoting  the  assimilation  process  or  constraining  it. 
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For  example,  the  presence  of  senior  managers'  advocacy  may  be  critical  to  facilitating  assimilation, 
while  its  absence  could  be  a  significant  inhibitor.  We  believe  that  practitioners  need  to  understand 
the  workings  of  these  factors  in  the  assimilation  process  generally,  and  in  their  particular 
organizational  contexts  specifically.  Such  understanding  should  allow  them  to  realize  or  augment 
the  influence  of  those  factors  that  faciliate  successful  assimilation  of  CASE  tools,  while  minimizing 
or  eliminating  the  effect  of  those  factors  that  constrain  successful  assimilation  of  CASE  tools. 
Table  7  presents  a  summary  of  these  factors,  and  the  direction  of  their  influence. 

Table  7:  Factors  affecting  the  Successful  Assimilation  of  CASE  tools 


FACTOR 


IS   Personnel 


IS  Culture 


Senior  Management 
Advocacy 


Methodology 


User  Involvement 


Implementation  Strategy 


Facilitating   Successful 
CASE  Assimilation 


System  developers  are  result 
oriented  and  seek  functional 
or  analysis  careers 

IS  unit  is  not  protective  of  its 
turf;  sharing  responsibility  with 
and  relinquishing  control  to  users 

Senior  Managers  champion  CASE 
tools,  expending  personal  effort, 
influence,  and  resources 

Methodology-in-use  and  that  of 
CASE  tools  are  compatible 

Users  are  actively  involved  and 
even  directing  systems  projects 

Implementation  is  explicit,  phased 
and  incremental 


Constraining  Successful 
CASE  Assimilation 


System  developers  are  process 
oriented  and  seek  technical 
data  processing  careers 

IS  unit  is  protective  of  its  turf; 
retaining  responsibility  and 
control  vis-a-vis  users 

Senior  Managers  do  not  support 
CASE  tools,  nor  commit  time 
and  resources  to  them 

Indifferent 


Indifferent 


Indifferent 


The  following  are  our  recommendations  for  assessing  and  dealing  with  these  factors. 

IS  Personnel  Orientation 

CASE  tools  potentially  disrupt  the  way  in  which  system  developers  work,  changing  their  skill  and 
task  requirements,  and  threatening  their  job  security.  Many  system  developers  react  defensively, 
particularly  those  who  have  an  investment  in  their  technical  knowledge  and  experience,  and  who 
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derive  satisfaction  from  the  technical  activity  of  building  systems.  Resistance  from  system 
developers  can  be  handled  in  a  number  of  ways.  One  approach  is  to  give  system  developers  the 
option  to  move  into  more  technical  work,  such  as  tools  support  or  database  maintenance.  The 
expectation  here  is  that  self-selection  will  guarantee  that  process-oriented  types  will  move  out  of 
applications  development,  while  those  more  functionally  oriented  will  remain  to  use  the  CASE 
tools  and  interact  with  users.  Another  approach  is  to  change  the  career  paths  and  expectations 
within  the  systems  development  unit.  Developers  will  then  realize  that  to  have  successful  careers  in 
the  firm,  they  will  have  to  become  analysis-oriented,  be  users  of  tools,  and  forego  images  of 
technical  wizardry.  Those  who  are  not  comfortable  with  this  change  in  orientation  can  seek  careers 
elsewhere,  but  at  least  they  are  informed  that  their  prior  expectations  and  experiences  are  no  longer 
appropriate  guidelines  for  success  in  this  fiim  Their  choice  is  theirs:  "adapt  or  leave." 

This  approach  needs  to  be  coupled  with  strong  IS  management  support  for  the  CASE  tools,  for  if 
these  are  perceived  to  be  an  uncertain  strategy,  developers  are  unlikely  to  commit  to  an  orientation 
change.  One  IS  manager  commented:  "They  [the  IS  personnel]  are  willing  to  ...  almost  become 
rookies  again,  because  they  know  management  really  wants  it,  and  will  stick  by  them  and  reward 
them.  When  the  professional  sees  that  the  boss  understands  that  it  is  going  to  take  a  year,  that  it  is 
going  to  take  some  pain,  then  they  will  do  it."  This  approach  clearly  depends  on  the  availability  of 
education  and  training  courses,  and  on  management  allowing  for  the  training  time,  the  learning 
curve,  and  the  readjustment  problems  that  inevitably  ensue.  One  company  has,  in  addition  to 
normal  training  courses,  instituted  an  information  campaign  whereby  CASE  tools  and  their 
implications  are  explained  at  a  general  level  to  system  developers  and  users.  This  tactic  may  help  to 
dispel  some  of  the  rumors  and  misinformation  that  typically  accompany  a  controversial  innovation. 

Culture  of  Systems  Development 

This  factor  concerns  the  extent  to  which  the  systems  developers  and  managers  are  willing  to 
relinquish  or  at  least  share  control  and  responsibility  for  systems  with  users.  Many  companies 
reported  a  deeply  rooted  territorialism  within  the  IS  culture,  which  serves  as  a  critical  barrier  to 
allowing  users  to  take  responsibility  for  systems.  For  those  CASE  tools  that  depend  on 
comprehensive  and  accurate  requirements  definitions  (to  drive  subsequent  screen/report  design  and 
code  generation),  the  lack  of  user  involvement  will  inhibit  their  successful  use  and  assimilation  in 
the  organization.  While  we  believe  that  users  should  be  involved  in  all  systems  development 
efforts,  not  all  CASE  tools  and  not  all  organizations  operate  under  this  premise.  However,  for 
those  organizations  that  want  to  encourage  shared  responsibility,  and  where  turf  lines  have  been 
carefully  delineated  in  the  past,  cultural  change  can  be  encouraged  through  education,  joint  task 
forces  at  multiple  levels,  and  management  advocacy  of  the  changed  work  norms. 
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Methodology 

We  believe  that  the  relationship  between  a  well-articulated  systems  development  methodology  and 
a  set  of  CASE  tools  should  be  a  mutually  reinforcing  one.  That  is,  the  methodology  should  inform 
the  assumptions  and  conceptual  structure  of  the  tools,  so  that  they  operate  consistently,  in  an 
integrated  fashion,  and  in  concert  according  to  some  common  logic.  On  the  other  hand,  the  tools 
should  enforce  the  logic  and  assumptions  of  the  methodology  (e.g.,  through  ensuring  compliance 
to  standards),  and  provide  automated  means  to  support  the  labor  intensive  activities  required  by  the 
methodology.  Given  this  symbiotic  relationship,  it  is  clear  that  there  are  advantages  to  having  the 
methodology-in-use  in  an  organization's  systems  development  practices  be  compatible  with  the 
methodology  underlying  a  set  of  CASE  tools.  Interactions  between  these  methodologies  will  be 
transparent,  and  there  will  be  less  training  requirements  and  less  need  to  enforce  different 
standards.  These  advantages  can  decrease  the  development  times,  as  there  is  no  need  to  translate 
between  different  world  views.  One  systems  developer  commented  about  the  ease  of  transition 
among  the  development  stages:  "The  programming  was  like  falling  off  a  log.  It  really  was  a  mirror 
translation  process  of  the  design  deliverables ..." 

We  recommend  that,  where  possible,  companies  attain  consistency  between  their  CASE  tools  and 
the  methodology-in-use  in  their  IS  organizations.  This  will  mean  either  acquiring  a  set  of  CASE 
tools  that  conform  to  the  existing  methodolgy-in-use,  or  changing  the  methodology-in-use  to 
reflect  the  methodology  of  the  CASE  tools  adopted.  The  latter  approach  is  clearly  the  more  radical 
action  and  needs  to  be  carefully  justified.  It  may  be  an  opportunity  to  adopt  a  more  appropriate 
methodology  (for  example,  if  a  data-oriented  methodology  is  seen  as  more  suitable  to  the  new 
database  architecture  of  the  organization),  on  the  other  hand  it  may  be  disruptive  and  expensive 
(provoking  resistance  and  lowering  morale). 

Senior  Management  Advocacy 

With  regards  to  senior  management  advocacy  our  contention  is  that  as  with  any  major 
organizational  innovation,  managerial  commitment  is  a  necessary  (although  not  sufficient) 
condition  for  successful  implementation.  It  is  clearly  an  important  facilitator  of  success,  in  that  it 
can  expedite  the  assimilation  of  a  new  endeavor  through  motivational  as  well  as  financial  and 
institutional  resources.  We  believe  that  its  presence  is  critical,  and  where  it  is  unavailable  the  CASE 
assimilation  process  will  be  problematic  and  outcomes  will  be  uncertain.  Thus,  if  senior  managers 
do  not  advocate  an  innovation,  this  can  serve  as  a  significant  constraint  on  successful  assimilation. 
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User  Involvement 

The  role  of  users  in  the  use  of  CASE  tools  was  an  important  outcome  as  well  as  a  facilitator  of 
CASE  assimilation  in  all  of  the  companies  we  examined.  Some  of  this  interaction  is  a  consequence 
of  the  IEW  CASE  tools  we  investigated,  as  they  encourage  and  depend  on  significant  amounts  of 
user  participation.  However,  we  suspect  that  user  pressure  on  the  IS  unit  can  be  an  important 
influence  on  the  manner  and  speed  with  which  any  set  of  CASE  tools  are  deployed  in  an 
organization.  The  users  in  our  study  felt  that  one  of  the  most  important  implications  of  the  CASE 
innovation  was  that  it  finally  put  control  of  the  system  characteristics  in  the  hands  of  the  users. 
Through  their  participation  and  direction  of  the  BAA  phase  of  the  IE  methodology,  users  were 
finally  able  to  exert  influence  on  how  their  systems  turned  out.  While  the  IE  methodology  with  its 
BAA  phase  can  be  used  without  CASE  tools,  we  found  that  the  BAA's  were  greatly  facilitated  by 
the  capabilities  of  the  DEW.  In  those  companies  using  IE  before  IEW,  enthusiasm  with  BAA  was 
much  less  as  all  the  information  being  generated  had  to  be  recorded  manually.  The  tediousness  and 
error-prone  nature  of  this  endeavor  served  to  discourage  extensive  emphasis  on  this  phase.  The 
IEW  CASE  tools  have  greatly  facilitated  this  activity  and  given  users  a  meaningful  voice  in  their 
systems.  While  we  believe  it  is  possible  to  implement  CASE  tools  in  organizations  without 
drawing  on  user  participation,  we  do  recommend  that  IS  managers  encourage  and  expedite  the 
active  engagement  by  users  in  systems  development  as  much  as  possible.  Not  only  will 
responsibility  for  systems  be  shared  and  the  quality  of  systems  should  improve,  but  the  use  and 
assimilation  of  CASE  tools  should  be  promoted. 

Implementation  Strategy 

In  the  section  above  we  described  three  kinds  of  implementation  strategy  that  our  sample  of 
companies  displayed.  We  suggest  that  which  implementation  strategy  (vertically  phased, 
horizontally  phased,  or  combination  phased)  is  adopted  is  less  important  than  that  some  explicit 
strategy  be  followed.  Carefully  articulating  the  manner,  timing,  and  phases  of  diffusing  the  CASE 
tools  structures  the  way  in  which  people,  both  systems  developers  and  users,  perceive  and  use  the 
tools.  It  also  serves  to  organize  training  activities  and  creates  the  impression  that  the  company  is 
systematic  about  its  adoption  of  the  innovation.  Along  with  articulating,  choosing  and  following  an 
implementation  strategy,  organizations  will  need  to  customize  the  methodology  and  the  use  of 
CASE  tools  to  reflect  their  specific  contexts.  Standards,  procedures,  controls,  and  policies  have  to 
be  drawn  up  to  specify  changes  in  deliverables,  time-frames,  and  expectations,  as  well  as  to  clearly 
delineate  the  role  to  be  played  by  the  automated  aids,  the  system  developers,  and  the  users.  CASE 
tools  change  the  ground  on  which  systems  are  built,  and  these  changes  must  be  formalized  and 
communicated  to  realize  their  benefits. 
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6.  CONCLUSION 

There  have  been  few  previous  studies  of  the  deployment  of  CASE  tools,  and  even  fewer  of  the 
processes  by  which  these  tools  are  assimilated  into  organizations.  In  the  study  reported  here,  we 
found  a  process  of  assimilating  the  CASE  tools  that  differed  in  emphasis  from  that  found  with 
other  innovations.  We  also  identified  a  number  of  factors  that  appear  to  influence,  sometimes 
substantially,  the  process  of  assimilation.  We  believe  that  the  articulation  of  these  factors,  and  an 
understanding  of  their  role  in  facilitating  and  constraining  successful  assimilation,  are  useful  to 
practitioners  who  are,  or  are  considering  implementing,  CASE  tools  in  their  organizations. 

The  study  also  has  some  implications  for  future  research.  First,  the  factors  identified  in  Table  7, 
and  their  expected  influence  on  the  process  of  CASE  assimilation  is  exploratory  and  needs 
extensive  verification  and  application  in  other  settings.  Further  many  potential  factors  for  which 
there  was  insufficient  information  in  this  study  may  well  be  relevant  influences  on  the  assimilation 
process.  These  need  to  be  investigated.  For  example,  one  of  the  criteria  for  selecting  the 
organizations  in  our  sample  was  size,  so  we  could  not  consider  its  role  in  the  assimilation  process. 
This  may  be  an  interesting  variable  for  future  research,  as  might  CEO  (and  even  CIO)  tenure, 
education,  and  attitude  towards  innovation.  Market  strategy  of  the  organization  was  not  considered 
relevant  as  the  concern  in  this  study  was  the  assimilation  of  CASE  tools  by  IS  departments  to  build 
systems  for  users,  rather  than  with  assimilating  a  technology  to  service  outside  customers. 
However  it  is  feasible  that  where  an  organization's  business  is  to  provide  information  products  and 
services  to  outside  clients,  market  strategy  may  well  affect  the  process  of  assimilating  CASE  tools. 
Further,  if  a  different  view  is  taken  of  the  IS  department,  as  a  unit  servicing  clients  (even  though 
these  are  internal  clients),  then  some  measure  of  departmental  service  strategy  may  be  a  significant 
influence  on  why  and  how  CASE  tools  are  assimilated 

Finally,  future  research  should  examine  other  CASE  tools,  as  this  study  only  investigated  one 
particular  CASE  toolset,  IEW.  While  we  believe  that  the  assimilation  process  and  many  of  the 
factors  we  identified  are  relevant  across  CASE  toolset  types,  our  findings  can  only  cautiously  be 
applied  to  CASE  tools  in  general.  As  we  noted  earlier,  the  varieties  and  flavors  of  CASE  tools  are 
many,  and  attributes  of  the  technological  innovation,  the  CASE  tools,  can  be  expected  to  influence 
the  assimilation  process.  Careful,  comparative  studies  across  this  range  are  needed. 

In  this  paper  we  articulated  a  process  by  which  CASE  tools  are  assimilated  into  organizations,  and 
explored  how  this  process  is  influenced  by  various  organizational  and  technological  factors. 
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Findings  from  an  empirical  investigation  revealed  that  nominal  amounts  of  time  and  effort  are  spent 
on  evaluating  the  CASE  tools  prior  to  their  adoption,  and  that  as  a  result,  organizational 
consequences  of  these  tools  were  poorly  understood  and  dealt  with.  We  identified  and  discussed  a 
number  of  key  factors  that  we  believe  facilitate  and  constrain  the  process  of  CASE  tools 
assimilation  in  organizations.  We  discussed  the  implications  of  these  findings  for  research  and 
practice,  and  proposed  some  recommendations  for  managing  the  implementation  of  CASE  tools. 
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